task_procedure:
  IN:
    nexts: ["Task_A", "Task_B1"]
    wait_until: []

  Task_A:
    nexts: ["Task_A_save_results", "Task_C"]
    wait_until: ["IN"]

  Task_A_save_results:
    nexts: ["OUT"]
    wait_until: ["Task_A"]

  Task_B1:
    nexts: ["Task_B2"]
    wait_until: ["IN"]

  Task_B2:
    nexts: ["Task_C"]
    wait_until: ["Task_B1"]

  Task_C:
    nexts: ["Task_C_save_results", "Task_B3", "Task_D1"]
    wait_until: ["Task_A", "Task_B1", "Task_B2"]

  Task_C_save_results:
    nexts: ["OUT"]
    wait_until: ["Task_C"]

  Task_B3:
    nexts: ["Task_D2"]
    wait_until: ["Task_B1", "Task_C"]

  Task_D1:
    nexts: ["OUT"]
    wait_until: ["Task_B1", "Task_C"]

  Task_D2:
    nexts: ["OUT"]
    wait_until: ["Task_B3", "Task_C"]

  OUT:
    nexts: []
    wait_until: ["Task_A_save_results", "Task_C_save_results", "Task_D1", "Task_D2"]

--------------------------------------------

이 DAG의 의미는 단순하다.

- Task_B1이 먼저 증거 식별자 권위본을 만든다.

- Task_B2는 그 권위본을 사용하여 raw evidence를 event-level intermediate로 분해한다.

- Task_C는 raw evidence_all.json 대신 evidence_event_candidates.json을 읽어 BO를 만든다. 따라서 토큰 폭발을 줄이면서도, meeting에 없는 사건행위를 evidence에서 보완하는 본래 목적은 그대로 달성된다.

- Task_B3는 Task_C가 남긴 사해행위 의심 신호를 이용하여 정확한 actio support만 추출한다.

- Task_D1과 Task_D2는 기존 철학을 거의 유지한다. D1은 BO를 1차 소스로 fact를 만들고, D2는 BO와 actio support를 조인한다.

--------------------------------------------

1. 새 번호 체계와 역할 재정의

이제부터 번호는 아래 의미로 고정하는 것이 맞다.

- Task_B1: 증거 authority catalog 생성
  - evidence_all.json → evidence_indexed.json

- Task_B2: 증거문서 사건행위 후보 추출 (신설; 당신의 요구사항 2)
  - evidence_all.json + evidence_indexed.json → evidence_event_candidates.json

- Task_C: 사건구조 합성
  - client_meeting.md + Juristic_Act.md + evidence_event_candidates.json + evidence_indexed.json → BO.json + actio_case_signals.json

- Task_B3: 사해행위 support 추출 (기존 Task_B2의 개명판; 당신의 요구사항 1, 3)
  - evidence_indexed.json + evidence_all.json + client_meeting.md + BO.json + actio_case_signals.json → evidence_actio_support.json

이 구조가 되어야 Task_B3가 단순 문서 스캐너가 아니라, Task_C가 이미 파악한 사건 구조와 사해행위 의심 정황을 이용하는 scoped extractor가 된다. 이것이 당신의 요구사항 1의 정확한 구현이다.

--------------------------------------------

# Task_A
IN: client_meeting.md
OUT: client_goal.json

# Task_B1
IN: evidence_all.json
OUT: evidence_indexed.json 

--------------------------------------------

4. Task_B1 재설계안

Task_B1의 본질은 유지하되, 역할을 더 엄격하게 제한해야 한다. 현재 B1은 이미 token-lean catalog를 만드는 authority task로 설계되어 있고, actio support는 만들지 않도록 되어 있다. 이 점은 유지하는 것이 맞다.

Task_B1의 수정된 역할
- evidence_indexed.json의 유일한 권위본 생성
- evidence_index, title, doc_type, source_pointer.ordinal의 안정적 부여
- 최소 key_*와 선택적 base legal_calculation_object만 생성
- 절대 하지 말아야 할 일
  - BO 추출
  - event candidate 분해
  - actio support 생성

5. Task_B2 재설계안

Task_B2의 역할
- evidence_indexed.json의 evidence_index와 source_pointer.ordinal을 기준으로
- evidence_all.json 각 문서를
  - 법적 중요 사건행위 후보들의 리스트로 분해하여
  - evidence_event_candidates.json을 생성한다.

입력과 출력
- IN: evidence_indexed.json, evidence_all.json, client_meeting.md
- OUT: evidence_event_candidates.json

여기서 client_meeting.md는 사건을 덮어쓰는 용도가 아니라, 당사자 alias 정규화, 사건상 중요도 판단의 보조, 금액/대상물 표현의 문맥보조에만 사용한다.


--------------------------------------------

6. Task_C 재설계안

Task_C의 역할 재정의
- client_meeting.md에서 BO 후보 생성
- evidence_event_candidates.json에서 meeting에 없는 BO 후보 보강
- 중복 제거
- Juristic_Act.md를 이용해 ActionType, JuristicAct 확정
- 시간순 정렬, PriorAct, Reason 구성
- 증거 매칭은 evidence_indexed.json 기준으로 수행
- 동시에 사건 전체를 훑어 사해행위 의심 구조가 있는지 machine-readable하게 기록

새 입력
- client_meeting.md
- evidence_event_candidates.json
- evidence_indexed.json
- Default_Agent/Juristic_Act.md

새 출력
- BO.json
- actio_case_signals.json
- Task_C_result.md (human-readable summary; 기존 유지)

나는 여기서 actio_case_signals.json을 추가하는 것이 필수라고 본다. B3가 markdown 문장을 파싱하도록 만드는 것은 결정론적으로 매우 나쁘다. Task_C의 “사해행위 의심 정황”은 machine-readable JSON으로 남겨야 한다.

`actio_case_signals.json` 최소 구조
```
{
  "is_actio_pauliana_suspected": true,
  "suspicion_level": "high",
  "suspicion_reasons": [
    "채무자 자산 처분 후보가 존재함",
    "원고채권 존속 후보가 존재함"
  ],
  "related_bo_ids": ["bh11", "bh12"],
  "related_evidence_indexes": ["E-014", "E-015"],
  "target_property_candidates": ["여의도 장미아파트 14동 101호"],
  "fraudulent_act_date_candidates": ["2016-01-31"],
  "preserved_claim_candidates": [
    {
      "bo_id": "bh2",
      "claim_type_candidate": "보증/구상",
      "creditor_candidate": "원고",
      "debtor_candidate": "채무자"
    }
  ],
  "beneficiary_candidates": ["수익자 성명"],
  "encumbrance_related_evidence_indexes": ["E-016", "E-017"]
}
```

--------------------------------------------

7. Task_B3 재설계안

이제 B3는 더 이상 “blind doc-level actio extractor”가 아니다.
반드시 Task_C가 남긴 사건 구조와 사해행위 의심 신호를 이용해야 한다.

새 입력
- evidence_indexed.json
- evidence_all.json
- client_meeting.md
- BO.json
- actio_case_signals.json

출력
- evidence_actio_support.json

역할
- Task_C가 사해행위 의심을 기록했을 때
  - 관련 목적물, 관련 보전채권, 관련 부담·임차권·가압류, 수익자 이익 후보를 중심으로
  - 문서별 sparse actio support를 정밀 추출한다.

핵심 원칙
- Task_C가 identified한 목적물/BO/증거를 우선 스코핑한다.
- 사건 전체를 다시 백지에서 actio로 분류하지 않는다.
- fraudulent_act_date는 Task_C가 잡아낸 목적물 처분 cluster에 직접 속하는 문서에서만 candidate로 올린다.
- proof_doc는 현재 문서의 evidence_index만 사용한다.
- 출력 스키마는 기존 evidence_actio_support.json과 호환되게 유지한다. 그러면 D2는 거의 그대로 둘 수 있다.


--------------------------------------------

9. 최종 정리

최종적으로 Stage 1의 B 계열은 아래 3층으로 나뉘는 것이 맞다.

B1 = authority layer
  - evidence_all.json → evidence_indexed.json

B2 = event decomposition layer
  - evidence_all.json + evidence_indexed.json → evidence_event_candidates.json

B3 = actio support layer
  - evidence_all.json + evidence_indexed.json + BO.json + actio_case_signals.json → evidence_actio_support.json

그리고 Task_C는 그 사이에서 meeting + evidence event candidates를 결합하여 BO와 사건 구조를 확정하는 synthesis layer가 된다.

이 설계가 좋은 이유는 단순하다.
  - B1은 식별자 권위본을 안정화한다.
  - B2는 token-lean catalog가 잃어버린 문서 내부 다중 사건행위 정보를 복원한다.
  - C는 raw evidence 대신 event-level intermediate를 사용하므로 토큰 폭발을 피한다.
  - B3는 C가 파악한 사건 구조를 이용해 사해행위 support를 정확히 스코핑한다.
  - D1과 D2, 그리고 Stage 2의 E-### 중심 조인 구조와도 자연스럽게 이어진다.

원하면 다음 단계로 바로 이어서, 내가 위 설계를 기준으로 Legal_Agent_V4_v3.yaml에 실제로 삽입할 수 있는 Task_B2, Task_C, Task_B3의 완성형 prompt 본문과 task_procedure patch를 YAML 형식으로 통째로 작성

--------------------------------------------

# stage1_task_B2_C_B3_patch.yaml

이 patch는 현재 Stage 1의 구조, 즉 Task_B1 뒤에 곧바로 기존 Task_B2가 evidence_actio_support.json을 만들고, Task_C는 별도로 client_meeting.md, evidence_all.json, Juristic_Act.md를 읽어 BO.json을 만든 뒤, Task_D1이 BO.json + evidence_indexed.json, Task_D2가 BO.json + evidence_actio_support.json을 사용하는 구조를 전제로 작성했다. 따라서 B 계열의 역할만 재배치하고 D1/D2의 기존 인터페이스는 최대한 보존했다.

적용 방식은 네 줄로 요약된다.
  - Task_B2 기존 블록을 patch의 새 Task_B2로 교체
  - Task_C 기존 블록을 patch의 새 Task_C로 교체
  - 새 Task_B3 블록을 Task_C 뒤, Task_C_save_results 앞에 삽입
  - stage1_사건개요파악.task_procedure를 patch의 task_procedure로 교체

























# Stage 2를 위해 알고 있어야 할 전제 지식


stage1_yaml_patch_proposal.md

--> Task_B1 

실무적으로는 이 patch를 적용한 뒤, 다음 단계로 Stage 2의 claim_information 생성기에서 evidence_ref_structs, asset_scope_key, fact_role_candidate를 실제로 소비하도록 수정해야 한다. 그래야 Stage 1에서 만든 안전장치가 Stage 2에서 완전히 효력을 가진다.

---

Task_B1 

교체용 프롬프트
```
- task_name: Task_B1
  llm_provider: google
  llm_model: gemini-3.1-flash-lite-preview
  llm_reasoning: medium
  use_tools: [localdocs]
  prompts:
    - role: user
      content: |
        ## 실행방법(체크리스트)
        [ ] 1) Preflight: `list_docs` 사용해서 `evidence_all.json`, `client_meeting.md`만 확인하고, `read_docs` 사용해서 `evidence_all.json`, `client_meeting.md`만 읽기
        [ ] 2) `write_file` 사용해서 `evidence_indexed.json` 생성
        [ ] 3) `list_docs` 사용해서 `evidence_indexed.json` 파일만 존재 확인(절대 읽기 금지)
        [ ] 4) `"증거문서 인덱싱 완료"` 출력하고 작업 종료

        ## 역할/목적
        당신은 Stage 1의 증거 authority catalog 생성기다.
        이 작업의 유일한 목적은 `evidence_all.json`에 안정적인 `E-###` 인덱스를 부여하고,
        후속 단계가 사용할 수 있는 경량 증거 카탈로그 `evidence_indexed.json`을 만드는 것이다.

        ## 필수 IO
        ### IN
        - evidence_all.json
        - client_meeting.md

        ### OUT
        - evidence_indexed.json

        ## 핵심 규칙
        1. `evidence_indexed.json`은 이후 모든 단계가 신뢰하는 유일한 증거 authority다.
        2. `source_pointer.ordinal`은 반드시 원본 `evidence_all.json` 배열 순서와 정확히 일치해야 한다.
        3. `evidence_index`는 E-001부터 순서대로 부여한다.
        4. `key_facts`, `key_dates`, `key_amounts`, `key_parties`는 최소한으로만 추출한다.
        5. `legal_calculation_object`는 현재 문서가 직접 뒷받침할 때만 선택적으로 1개까지 허용한다.
        6. `actio_pauliana_support`는 절대 생성하지 않는다.
        7. event-level 분해는 절대 하지 않는다. 그것은 `Task_B2`의 책임이다.
        8. 원문 대량 복사 금지. 요약, 정규화, 포인터 중심으로만 작성한다.
```

Task_B2

교체용 프롬프트 
```
- task_name: Task_B2
  llm_provider: google
  llm_model: gemini-3.1-flash-lite-preview
  llm_reasoning: medium
  use_tools: [localdocs]
  prompts:
    - role: user
      content: |
        ## 실행방법(체크리스트)
        [ ] 1) Preflight: `list_docs` 사용해서 `evidence_indexed.json`, `evidence_all.json`, `client_meeting.md`만 확인하고, `read_docs` 사용해서 세 파일만 읽기
        [ ] 2) `write_file` 사용해서 `evidence_event_candidates.json` 생성
        [ ] 3) `list_docs` 사용해서 `evidence_event_candidates.json` 파일만 존재 확인(절대 읽기 금지)
        [ ] 4) `"증거문서 사건행위 후보 추출 완료"` 출력하고 작업 종료

        ## 역할/목적
        당신은 Stage 1의 증거-사건행위 분해기다.
        `evidence_indexed.json`을 authority로 사용하여, `evidence_all.json` 각 문서에서
        권리/의무/책임의 발생·변경·소멸과 관련된 법적 중요 사건행위 후보를 빠짐없이 추출한다.

        ## 필수 IO
        ### IN
        - evidence_indexed.json
        - evidence_all.json
        - client_meeting.md

        ### OUT
        - evidence_event_candidates.json

        ## 불가침 원칙
        1. `evidence_indexed.json`의 `evidence_index`와 `source_pointer.ordinal`을 유일한 문서 식별 기준으로 사용한다.
        2. 한 문서에 여러 사건행위가 있으면 반드시 여러 `event_candidates`로 분해한다.
        3. 문서 단위 1요약으로 뭉개지 않는다.
        4. `client_meeting.md`는 alias 정규화와 중요도 보조에만 사용한다.
        5. 문서에 없는 사건행위를 meeting만으로 새로 만들지 않는다.
        6. 최종 BO, 최종 JuristicAct, 최종 청구권은 결정하지 않는다.
        7. 이 단계는 candidate layer다. 확정 판단을 금지한다.
        8. 원문 장문 복사 금지. `support_locators.excerpt`는 짧게 유지한다.

        ## 추출 대상
        - 소유권 이전 / 매매 / 증여 / 대물변제
        - 근저당·저당 설정 / 말소
        - 대여 / 보증 / 신용보증 / 대위변제 / 구상권 발생 / 변제 / 배당
        - 임대차 / 임차보증금
        - 가압류 / 압류 / 강제집행 관련 기재
        - 통지 / 최고 / 판결·결정 등 법적 중요 사건행위

        ## 산출 규칙
        1. 출력은 문서별 레코드 배열이되, 각 레코드에는 `event_candidates` 배열을 둔다.
        2. `event_candidates[].candidate_id`는 반드시 `E-###-EC-##` 형식을 사용한다.
        3. `identity_signature`는 Task_C의 meeting-기반 BO와 중복 제거할 때 사용할 수 있도록
           `(행위종류 + 핵심당사자 + 핵심목적물/금액 + 날짜)`를 정규화한 문자열로 만든다.
        4. `actio_relevance_candidates`는 최종 판단이 아니라 후보 태그만 남긴다.
        5. `fraudulent_act_date_candidate`는 현재 candidate가 직접 목적물 처분/이전과 연결될 때만 기입한다.
        6. 문서에서 직접 뒷받침되지 않으면 `null` 또는 빈 배열로 두되, 최종 출력에서는 pruning한다.
```


Task_C 의 actio_case_signals.json 최소 구조

```
{
  "is_actio_pauliana_suspected": true,
  "suspicion_level": "high",
  "suspicion_reasons": [
    "채무자 자산 처분 후보가 존재함",
    "원고채권 존속 후보가 존재함"
  ],
  "related_bo_ids": ["bh11", "bh12"],
  "related_evidence_indexes": ["E-014", "E-015"],
  "target_property_candidates": ["여의도 장미아파트 14동 101호"],
  "fraudulent_act_date_candidates": ["2016-01-31"],
  "preserved_claim_candidates": [
    {
      "bo_id": "bh2",
      "claim_type_candidate": "보증/구상",
      "creditor_candidate": "원고",
      "debtor_candidate": "채무자"
    }
  ],
  "beneficiary_candidates": ["수익자 성명"],
  "encumbrance_related_evidence_indexes": ["E-016", "E-017"]
}
```

Task_C 교체용 프롬프트

```
- task_name: Task_C
  llm_provider: anthropic
  llm_model: claude-opus-4-5
  use_tools: [localdocs]
  prompts:
    - role: user
      content: |
        ## 실행방법(체크리스트)
        [ ] 1) Preflight: `list_docs` 사용해서 `client_meeting.md`, `evidence_event_candidates.json`, `evidence_indexed.json`, Default_Agent/Juristic_Act.md만 확인하고, `read_docs` 사용해서 해당 파일만 읽기
        [ ] 2) `write_file` 사용해서 `BO.json` 생성
        [ ] 3) `write_file` 사용해서 `actio_case_signals.json` 생성
        [ ] 4) `list_docs` 사용해서 `BO.json`, `actio_case_signals.json` 파일 존재만 확인(절대 읽기 금지)
        [ ] 5) `"사건개요를 구조적으로 파악"` 출력하고 작업 종료

        ## 역할/목적
        당신은 Stage 1의 사건구조 합성기다.
        `client_meeting.md`의 진술과 `evidence_event_candidates.json`의 증거기반 사건행위 후보를 통합하여
        `BO.json`을 생성하고, 동시에 사건에 사해행위취소 구조가 의심되는지 기록한다.

        ## 필수 IO
        ### IN
        - client_meeting.md
        - evidence_event_candidates.json
        - evidence_indexed.json
        - Default_Agent/Juristic_Act.md

        ### OUT
        - BO.json
        - actio_case_signals.json

        ## 핵심 규칙
        1. meeting 기반 BO와 evidence 기반 event candidate를 통합한다.
        2. evidence에서 meeting에 없는 법적 중요 행위는 BO로 추가한다.
        3. 중복 판정은 `identity_signature`와 `(행위종류 + 핵심당사자 + 핵심목적물/금액 + 날짜)`를 함께 사용한다.
        4. `ActionType`, `JuristicAct`는 반드시 Juristic_Act.md를 기준으로 분류한다.
        5. `Evidence`는 `evidence_indexed.json`의 authority를 기준으로 연결한다.
        6. `EvidenceTitles`는 `Evidence[].source_title`의 uniq와 완전 일치해야 한다.
        7. raw evidence 본문을 다시 뒤지지 않는다. evidence 측 입력은 `evidence_event_candidates.json`과 `evidence_indexed.json`으로 한정한다.
        8. BO 생성과 별도로, 사건 전체에서 아래 정황이 함께 포착되면 `actio_case_signals.json`에 기록한다:
           - 자산 처분/이전 후보
           - 원고채권 존속 후보
           - 수익자/전득자 후보
           - 부담·임차권·가압류 등 가치공제 관련 후보
           - 처분시점 후보
        9. `actio_case_signals.json`은 최종 법률판단이 아니라 suspicion record다.

        ## actio_case_signals 기록 규칙
        - `is_actio_pauliana_suspected`는 true/false로 명시
        - suspicion_level은 `high|medium|low|none`
        - 관련 BO, 관련 evidence, 목적물 후보, 처분일 후보, 보전채권 후보를 구조화해서 남긴다
        - markdown 서술이 아니라 JSON 구조로 남긴다
```



Task B3 교체 프롬프트

```
- task_name: Task_B3
  llm_provider: google
  llm_model: gemini-3.1-flash-lite-preview
  llm_reasoning: medium
  use_tools: [localdocs]
  prompts:
    - role: user
      content: |
        ## 실행방법(체크리스트)
        [ ] 1) Preflight: `list_docs` 사용해서 `evidence_indexed.json`, `evidence_all.json`, `client_meeting.md`, `BO.json`, `actio_case_signals.json`만 확인하고, `read_docs` 사용해서 해당 파일만 읽기
        [ ] 2) `write_file` 사용해서 `evidence_actio_support.json` 생성
        [ ] 3) `list_docs` 사용해서 `evidence_actio_support.json` 파일만 존재 확인(절대 읽기 금지)
        [ ] 4) `"사해행위취소 support 인덱싱 완료"` 출력하고 작업 종료

        ## 역할/목적
        당신은 Stage 1의 사해행위취소 support 추출기다.
        다만 이 작업은 백지상태에서 수행되지 않는다.
        반드시 `Task_C`가 생성한 `BO.json`과 `actio_case_signals.json`을 읽고,
        그 사건 구조 및 의심 정황을 기준으로 scoping한 뒤 문서별 sparse support를 생성한다.

        ## 필수 IO
        ### IN
        - evidence_indexed.json
        - evidence_all.json
        - client_meeting.md
        - BO.json
        - actio_case_signals.json

        ### OUT
        - evidence_actio_support.json

        ## 핵심 규칙
        1. `actio_case_signals.json.is_actio_pauliana_suspected == false`이면 원칙적으로 매우 보수적으로 추출하거나 `[]`를 저장한다.
        2. 관련 목적물, 관련 BO, 관련 evidence, 관련 처분일 후보가 있는 경우에만 적극적으로 support를 추출한다.
        3. `fraudulent_act_date`는 목적물 처분/이전 문서와 직접 연결되는 경우에만 채운다.
        4. 원고채권 snapshot, 부담, 임차권, 가압류, 수익자이익도 Task_C가 남긴 cluster 안에서만 스코핑한다.
        5. `proof_doc`는 반드시 현재 문서의 `evidence_index`다.
        6. base catalog 필드(`title`, `doc_type`, `key_*`, `legal_calculation_object`)는 반복 저장하지 않는다.
        7. 최종 결론값(common_collateral_value, preserved_claim_total, recovery_cap 등) 계산 금지.
        8. 이 단계는 문서별 sparse support delta만 생성한다.

        ## actio scoping 우선순위
        1. `actio_case_signals.related_evidence_indexes`
        2. `actio_case_signals.target_property_candidates`
        3. `actio_case_signals.fraudulent_act_date_candidates`
        4. `actio_case_signals.preserved_claim_candidates`
        5. `BO.json`에서 관련 `Evidence[].evidence_index`
```

지금까지 다룬 모든 것들이 
stage1_task_B2_C_B3_patch.yaml
에 저장되어 있다. 

이후 Task D2 프롬프트도 재작성했고, Task_B3와 중복되는지 여부를 검토했다. 
--> 결론: fact_actio_support.json은 필요하다



stage1_task_D2_scoped_patch.yaml
-->
기술적으로는, 이전에 내가 제시한 stage1_task_B2_C_B3_patch.yaml 위에 이 파일만 추가 적용하면 된다. 그 prior patch의 task_procedure는 그대로 유지해도 되고, 이번 파일은 기존 Task_D2 블록만 교체하면 된다. Task_D2가 읽는 입력 파일만 actio_case_signals.json까지 확장된 것이다.


























